Business Analyst Community & Resources | Modern Analyst

Hey IIBA, What’s Up With That?

Howard Podeswa — Mon, 08 Oct 2012 06:07:00 GMT

Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession.

Hi xx

…. Regarding the IIBA talk, there is another issue that I am considering. It's part of a longer discussion, and I hesitate to draw you into it, but as it affects my response to your invitation I feel it requires some explanation. Basically, I have been very unhappy with the direction the organization has been taking and have been seriously reconsidering my - and my company's - relationship to it in lieu of recent developments. When I first joined the organization, back in its founding days, I, like many other volunteers who gave their time freely, without charge, to review the BABOK, saw the organization as a means for improving the profession by pooling together the resources of its practitioners so that best practices could be disseminated widely amongst the community. I fear the organization has steered off-track, and have great reservations regarding what it is becoming - or already has become. The recent EEP contract changes have only served to confirm my worst fears: students taking any training that 'uses' more than 3 sections of the BABOK will be required to purchase the entire BABOK - even if they already have a copy. In fact, it has been clarified to me that they will be required to purchase the book each time they take such a course - raising the spectre of trainees forced to purchase multiple copies of the BABOK due to courses they have taken with multiple vendors. It's a heavy-handed approach (and potential book-keeping nightmare) that will only serve to restrict the propagation of BABOK practices - where the IIBA should be seeking to do the reverse: open up the BABOK so it is as widely used as possible. For a comparison of approaches, see the OMG, which offers its UML standards and guidelines as a free download to all who want it (member or non-member) and which is very generous in providing permission to quote its text in printed publications. This is what an organization does whose first and foremost goals is to propagate best practices.

The IIBA faces an identity crisis: is it to be a revenue-generating machine, dedicated foremost to its own financial success, or a service to the BA profession?

These are some of my thoughts and concerns. If you'd like to continue this conversation, I'd be pleased to discuss it further.

Best regards
- Howard

Howard Podeswa - Noble Inc.

10 Things I Wish Someone Had Told Me When I Was Starting Out As A BA

Howard Podeswa — Tue, 15 Feb 2011 05:32:00 GMT

I am no longer a Webinar virgin. Thanks to the good folks at the IIBA, this week I had my first Webinar experience as an interviewee as part of the IIBA’s ‘ABC’ (Authors, Books and Conversations) series. The host, Julian Sammy, was brilliant in being able to pick out the questions that would be the most difficult for me to answer. (I hear that’s what makes him a great BA, too.) Of course, afterwards, I was regretting not being able to do a ‘do-over’ – until I remembered that I could – sort of – thanks to my MA blog.

Julian’s toughest questions were about the 3-way connection I saw between psychology, business analysis and art; I’ll leave that for later. But there was a BA question that I didn’t have a ready answer for, “What are the most important things you wish you had known when you were starting out as a BA?” Maybe it’s because it’s been so long since I have been in that position. But the memories have begun to come back.

So, for Julian - and anyone else who might be interested: here, then, after some thought, is what I wished someone had told me when I was starting out:
1. See every BA engagement as an opportunity to learn about other people - and not just to learn about another system: I thought my success or failure as a BA would be all about my analysis skills. I have since found out it hinges more on my ability to connect with people from a wide variety of backgrounds and cultures.

2. Turn off the inner monologue while listening to other people. (See #1 above).

3. Find out, from day 1, who will have ultimate signing authority – then meet that person as soon as possible: I’ve had bad shocks early in my career when I found out that the one person I really needed to convince was the one person I didn’t know about - until it was too late. I now do everything in my power to bring that person into the process ASAP.

4. Don’t go off for too long on your own: In my earlier days, I would do a big round of interviews and then go off for a long period to produce a big ‘tome’ of documentation. I found out soon enough that it’s too much for stakeholders to absorb at once and it’s too easy to propagate mistakes – like too much or the wrong kind of documentation. Now I provide feedback frequently to stakeholders.

5. The only way to get a good user interface is through many iterations of prototyping and user testing – because most people don’t know what they want till they see it. The focus of the BA in this case is to find out what the flow of the interface should be from the user’s perspective (the ‘Basic Flow’ – in use-case parlance), as well as the alternative scenarios that need to be addressed, while the designer works to realize these flows in the prototypes.

6. Test assumptions as early as possible in order to mitigate risk – especially if this is something you (or your organization) is doing for the first time: I’ve personally worked on 2 major projects where untested assumptions about new technology resulted in long delays and lots of rework once they were found to be untrue - and I have direct knowledge of many more projects that have suffered the same fate. By testing assumptions early I am now able to reduce the impact of unexpected problems.

7. Budget your time wisely: In the early days, I blew too much analysis time on small parts of the business area. I am much more careful now in planning and budgeting my time. I’ve learned to work top-down; in the beginning, I concentrate on the big picture and work my down into the weeds as the project progresses.

8. There is almost always a hidden agenda: For any non-trivial project, there is bound to be some aspect of office politics that can make or break the project. In many cases I have ended up being an unwitting pawn in someone else’s power play. In one case, for example, there were warring departments, each of which had already made up its mind about the preferred solution; the hidden agenda of the project champion who brought me onboard was to get an ‘unbiased expert’ to recommend his preference.

9. Don’t solutionize the requirements: The requirements as written, should make sense regardless of the technology solution. Otherwise, they will not be reusable should the preferred solution change – leading to lost time and effort.

10. The clients already know the answer: This is the secret lesson of consulting that I learned at the hands of a colleague (Brian Lyons) – and I’ve found it to be true more often than not. In many cases (such as process improvement projects), the clients know what’s wrong and what they need to do about it - and are really looking to the BA to confirm what they already know, or to help them formulate their thoughts. Yet another reason why it’s more important to listen than to talk.

And what about that question about psychology, business analysis and art (all of which are interests of mine)? The flippant answer is to say that these interests co-exist but they don’t necessarily connect. By maybe they do. I have an endless curiosity about people and how they live their lives – and it is a curiosity that the BA profession has helped me satisfy. As well, I have always been interested in the structure of thought – a theme that underlies both cognitive psychology as well as structural analysis. My art similarly has two recurring themes - often concerned either with the psychology of an interaction (see this series based on my experiences in South Africa) or with the way the mind organizes information (see this link for work based on organizing visual bytes of information).

So maybe there is some connecting thread to it after all.

- Howard Podeswa

What are the Quantitative Benefits of Business Analysis?

Howard Podeswa — Sat, 27 Nov 2010 08:21:00 GMT

At the end of my IIBA Webinar I tossed out a question to listeners: What are the quantitative benefits of business analysis?

It’s something I’ve been spending some time on. While there are many touted (and self-obvious) benefits of analysis , hard figures are hard to come by – and it’s hard figures that high-level executives want to see when we make the case for the profession. Fellow BAs have begun to take me up on the challenge and I have, at the same time, been meeting with CEO, CFOs, CIOs and others in upper-level management. So I thought it was time to throw out the question to the collective wisdom of the Modern Analyst community. What I’m looking for are measures that quantify either the benefits that have been derived from business analysis or the costs of doing it badly: metrics like the annual cost to projects attributable to a poor requirements analysis process relative to the annual project budget; estimated decrease in turnaround time due to improved analysis, and so on. I’m also looking for war stories – either horror stories of where things went wrong due to poor analysis or uplifting stories when things have gone well – with figures to back it all up where possible. Alternatively – if you have a source of stats on the cost benefits of good requirements that you think is helpful, please pass that one, too.

Readers are invited to post their contributions to this blog or, if confidentiality is required, to contact me directly at howardpodeswa@nobleinc.ca. Once I have a representative response, I’ll be summarizing and posting the results on this site.

(Attached jpg: Caption: “Hi-Lo”, Howard Podeswa, Oil on canvas, 2007, 10 “ x 10”. Description: “Hi-Lo” is a reconstruction of the painting “The Night Watch” by Rembrandt, created by measuring and graphing the high and low points in the original composition.)

Howard Podeswa of Noble Inc.

Blog Image: “Hi-Lo”, Howard Podeswa, Oil on canvas, 2007, 10 “ x 10”.

“Hi-Lo” is a reconstruction of the painting “The Night Watch” by Rembrandt, created by measuring and graphing the high and low points in the original composition.)

BA ABCs: “B” is for BPMN

Howard Podeswa — Sun, 12 Sep 2010 23:21:00 GMT

#2 in the series: “B” is for BPMN
This blog continues a series on BA tools, based on my book “The Business Analyst’s Handbook”. In each blog, I move through the alphabet, highlighting a BA tool that begins with the letter of the day. Today’s letter is “B” – for Business Process Modeling Notation (BPMN). BPMN is the name of a standard often used for modeling business processes. The diagram covered by the standard is called a Business Process Diagram (BPD).

Example:
Figure 1 is a BPMN BPD that describes the process for reserving a room in a private-members club. The process begins when a member requests a reservation for a specified date. A reservations agent determines the rate and then takes one or more of the followings actions:

If the request included a query about basic rooms, the reservations agent checks the availability of basic rooms.
If the request included a query about deluxe rooms, the reservations agent checks the availability of deluxe rooms.
The slash on the flow marked “Query basic rooms” is a default, indicating this flow is selected if none of the conditions are true.

Next, the member selects a room. When the member’s response is received by the reservations agent, one (and only one) of the following actions is taken:

If the member has cancelled, the reservations process is cancelled.
If the member has selected one of the available rooms, then the reservations agent guarantees the reservations and the process ends in success.

Figure 1 - BPD diagram example: Reserve a room in a private-members club

The controversy: Activity diagram or BPD?

Since activity diagrams (the subject of the previous BA ABCs blog) cover the same ground as BPMN BPDs, the question naturally arises, “Which diagram is ‘better’”? In fact, a controversy rages on this issue, with arguments made for and against each approach – so it’s worth exploring. One of the major advantages touted for the UML (the standard that governs activity diagrams) is that by providing a single standard across the lifecycle, translation errors are avoided. By this reasoning, it makes sense to use activity diagrams for both business process modeling and for modeling the logic of the software processes that automate them. On the other hand, the BPMN standard is often seen as the more natural candidate for the specific purpose of modeling business processes. In fact, the commonly accepted best practice is for BAs to use BPMN for this purpose (unless there is a compelling reason to use activity diagrams – such as the use of a UML tool across the project) and to use the UML for its other diagrams – primarily class diagrams. Let’s consider the arguments for and against each option to try to ferret out the truth.

Argument #1: Activity diagrams are technical whereas BPMN BPDs are business-y

Because the UML standard came out of the development world, its diagrams are thought to be code-oriented. But this is more an issue of perception than fact. In truth, the UML is a full-spectrum standard that supports both real-world and technical modeling. While it is certainly the case that there are features of activity diagrams that are technically oriented, the fact is that only a small subset of features should be used by the BA when communicating with business stakeholders – and this subset corresponds closely to commonly understood flowcharting symbols. (The same can also be said for BPMN.) I have a strong suspicion that the word ‘Business’ in the BPMN acronym has had as much impact as anything else in this perception of BPMN’s preferred status for business usage. But when you compare the aspects of the two alternatives that are actually used by the BA, feature by feature, there is in fact little difference between the two, as the next argument explains.

Argument #2: As a whole, BPMN diagrams are easier for business stakeholders to understand than activity diagrams

To get past the rhetoric, let’s compare the modeling elements most useful for BA purposes. Figures 2 and 3 show commonly used BPMN symbols along with their activity diagram counterparts. A quick glance indicates that it is hard to tell the two apart. When you look at these elements side by side you really have to wonder what all the fuss is about. There is one situation, in fact, that is expressed in a clearer manner (from a stakeholder’s perspective) in activity diagrams than on a BPMN BPD: parallel activities. Figure 4 compares the BPD and activity diagram symbols used to indicate two activities that may occur in parallel (meaning that they may occur in any order). I think most people would agree that the BPD symbol – a diamond with an enclosed ‘+’ sign, is much more cryptic than the straightforward parallel lines used for this purpose on activity diagrams.

Figure 2 - BPD flow objects (with UML equivalents)

Figure 3 - BPD connecting objects (with UML equivalents)

Figure 4 - BPD parallel fork (with UML equivalents)

Argument #3: BPMN includes special modeling elements that make it more suitable for business purposes than activity diagrams

Here I do believe there is some merit to the argument in favour of BPMN. One situation not well handled by activity diagrams is the Inclusive-OR. This is the logical construct used to model the common expression ‘and/or’ – as in: Do ‘A’ and/or ‘B’ and/or ‘C’ – depending on various conditions. Figure 5 illustrates the approaches used in the two standards. BPMN BPDs are clearly preferable to the mess of symbols required by activity diagrams. Another situation for which BPMN has a dedicated symbol relates to the handling of events. Figure 6 illustrates the difference between the two standards. BPMN relies on the placement of a circular event symbol to communicate to the reader the timing of a response to an event: an event symbol on an activity means that the event interrupts it whereas an event after an activity means that the activity first is completed and then the event is noted and responded to. Activity diagrams have a fairy simple alternative notation for this – but it may not be as readily obvious to the reader what is being conveyed.

Figure 5 - BPD inclusive gateway (with UML equivalent)

Figure 6 - BPD events (with UML equivalent)

Argument #4: BPMN models B2B interactions better than activity diagrams

In the ‘real world’, businesses interact with other businesses in limited ways, whereas organizational units within a single business have more complex interactions. In BPMN, this is modeled using pools and lanes. A business is represented as a pool and an organizational unit within the business is represented as a lane. Interactions between pools are limited to the passing of messages – effectively mirroring the way that businesses pass requests (messages) to each other while being unaware of each other’s internal processes. Figure 7 illustrates this approach. There is no formalism dedicated to this concept in activity diagrams, though the situation is fairly easily modeled by stipulating that businesses communicate by sending and receiving signals. Nevertheless, signals are not widely used for business process modeling and are less likely to be readily understood than pools by business stakeholders.

Figure 7 - BPMN B2B model using pools

Conclusion
For business process modeling, where all the players are within a single business, there is no compelling argument for either standard. While there are some small advantages to each standard, they tend to cancel each other out. (E.g., while BPMN handles the inclusive-or situation better, activity diagrams model parallel activities more clearly.) However, BPMN does have a clearer approach for modeling B2B interactions.

Final words
This discussion has focused entirely on the BA perspective. A separate set of arguments and comparisons could be made with respect to the suitability of the two alternatives for code generation. But that is a topic beyond the scope of this blog.

Howard Podeswa, author of Noble Inc.
For courses designed by the author in Business Process Modeling, click here: http://www.nobleinc.ca/BA005.html

BA ABCs: “A” is for Activity Diagram

Howard Podeswa — Mon, 17 May 2010 04:13:00 GMT

This blog begins a series on BA tools, based on my book “The Business Analyst’s Handbook”. In each blog, I’ll be moving through the alphabet, highlighting a BA tool that begins with the letter of the day (not quite Sesame Street, but not PeeWee ‘s Playhouse either). Today’s letter is “A” – for activity diagram.

Example:
The following activity diagram example describes a portion of the workflow for the business process, Review Pursuit – one of the processes within a Customer Relations Management (CRM) system. The two participants in the process are represented by the columns (referred to as swimlanes, or partitions), named “Growth and Markets” and “Pursuit Team.” The example indicates that the process starts when a Pursuit Team reviews an opportunity report. If the review has determined that the opportunity is not worth pursuing, the process ends. Otherwise, Growth and Markets schedules a post-review meeting and discusses required support.
This kind of diagram could have also illustrated which computer systems automated which activities, by depicting the systems as swimlanes - and, in fact, this is precisely what was done in the real case from which this example was derived.

Background on the example:
A number of years ago, I did some consulting for a financial investment firm. The goal of the project was to improve the business process workflow for tracking opportunities and proposals in a Customer Relations Management (CRM) system. The company had been using a number of software products to handle the process – CMS Open for one aspect and PeopleSoft for another. Amongst other things, they were unhappy with the amount of double entry they were doing – entering client information on one system while an initiative was at the proposal stage and doing it again on another system once the proposal was accepted. As a first step, I was asked to develop an As-Is workflow diagram for the current process. Suspecting that one must already exist, I asked to see it but was told that no, there was no diagram. After a while in this business, you develop a sixth sense for detecting when somebody is holding something back so I persisted – and sure enough, the interviewee pulled one out of his desk drawer. I knew it wasn’t perfect (which is why he hadn’t wanted to show it to me) but I was glad to have it – as it was a great aid in facilitating group interview sessions. It’s much easier to look at something and find the errors than to begin from scratch; or another way of putting it: better to have a straw man than no man at all.

The diagram I used showed the steps of the process and indicated who or what system was responsible for each step. This type of diagram is known by many names: Flowchart (which often only shows the sequence of actions but not who does them), Swimlane Workflow Diagram (where the doer of each action is shown) and (if you are using the UML standard) an activity diagram (which may or not show the doer, depending on how it’s drawn).

Context
Activity diagrams are useful in the situation I’ve described – when you need to analyze the workflow of an existing (As-Is) or future (To-Be) business process. In the UML, (using Rational Unified Process [RUP] terminology) are used this way when specifying business use-case realizations (descriptions of the internal workflow used to execute business processes). In this type of situation, they are drawn so that the doer is shown – by indicating a swimlane (or ‘partition’) for each participant.

Another context for using activity diagrams is in describing system use cases. A system use case is a user task – typically a task that a computer user expects to accomplish in a single session on with a software system. The requirements for the interaction between the user and system are usually described in text, but an activity diagram is added if the steps within the text connect to each other in complex ways. (The document that houses all of this is called, in RUP, a ‘use-case specification’.)

Howard Podeswa, author of Noble Inc.

Agile Development: What we can learn from property developers – or what they’ve learned from us

Howard Podeswa — Sun, 13 Dec 2009 05:01:00 GMT

Readers of this blog (both of you; I know you’re out there!) may have gathered by now that I’m a big fan of mixing it up: art/science/business/philosophy/politics/psychology and anything else that can be thrown into the pot. I believe that the more you let your worlds bleed into each other, the more opportunity there is to benefit from the cross-pollination of ideas.

I had a vivid example of this recently. I was having dinner with a friend of mine – who also happens to be a gifted architect and designer. We were talking about a project he is working on where he is responsible for handling design aspects of a large commercial property development. One of the things that struck him as particularly challenging on this project was the fact that the buildings were literally going up as the design was being worked on. This meant that many different activities were going on at the same time. Instead of going through a single pass of upfront design followed by construction, they were developing this project in a set of short cycles; each time through they pinned down the requirements for an aspect or area of the complex, did just enough design to get it built and then constructed it on the ground.

Sound familiar? What he was describing was iterative-incremental development – an approach to managing software projects that is the basis of agile approaches, IBM’s RUP (Rational Unified Process) and Microsoft’s MSF.

It’s interesting to note that the classic (i.e. older) approach to managing software projects was based on the how the construction industry managed its projects at that time: a single cycle of requirements analysis, design, testing and construction, known in the IT world as the ‘waterfall’ approach. That got me wondering whether the influence is now flowing on the opposite direction. Are managers of construction projects now learning a trick or two from their counterparts in the IT world?

These are not rhetorical questions. I’m expecting an answer – or at least looking forward to your comments, and maybe even instigating a little cross-breeding for those of you who have friends in the design or construction industry. To wit: Does anybody out there know when iterative development began to take off in the construction industry? For those of you with friends in the design, construction, or property development sectors: Do you know of any examples of iterative construction projects and, if so, what are the challenges and lessons learned?

By the way, I asked these questions of my friend, the architect, in order to see if there were any ‘lessons learned’ that could be applied to the IT world. He told me that the biggest challenge for the design shop, was to avoid making a decision they would later come to regret. This was a real risk, because they were designing while some of the requirements were still unknown. It’s a challenge BAs on iterative projects should all be able to appreciate. Asked how they were mitigating this risk, he summarized their approach as follows:

Don’t commit to something today that you can put off till tomorrow. In other words, if you can delay a decision without delaying the project, put the decision off. But if you have to make a decision, then …

Choose the option that least constrains the future. That way you minimize the impact of making a wrong decision.

Here’s an example of how the second principle works in his industry: The designers were required to put in a staircase before they even knew how the rooms on that floor were going to be used and what their individual sizes and layout would need to be. So the designers chose a staircase position that left them with the most flexibility for laying out the rooms later. In this case it meant rejecting a central staircase, because it would rule out options for room layouts more than a staircase off to one side.

You can see how these lessons can be immediately applied to IT projects. As to which sector originated the idea of iterative development, one thing is certain: Wherever the iterative idea started, everyone who is doing it – regardless of the sector they’re in – has a lot to learn from each other. Let’s get the conversation started.

Howard Podeswa, author of UML for the IT Business Analyst

Art and IT: Two Solitudes?

Howard Podeswa — Fri, 10 Jul 2009 04:01:00 GMT

In these ‘tough economic times’ everything seems to be measured in dollar value and if that kind of value isn’t readily discernable, we often assume there is no other value either – or none that matters. It’s behind personal financial expert Suze Orman’s diatribe against teachers (who, according to Suze, can’t possibly have any self-respect if they’re willing to work for so little money), and behind a general devaluation of arts and culture - other than those aspects that have a proven monetary value. I think we’re missing something that the artists and scientists of the Renaissance period understood well, when an artist, poet, architect and scientist were not necessarily different individuals.

These thoughts came to mind as I was showing a copy of the new edition of my book, UML for the IT Business Analyst to a friend who is an artist. I pointed out the new painting on the cover, and he recognized it right away from a previous exhibition. But there the interest ended. Unsurprisingly, he had no idea what the diagrams inside meant - but he could not even entertain the idea that he might be able to understand them. It got me wondering why it so unusual for somebody who works in the arts today to have an aptitude or interest in ‘computers’ (by which I really mean software design and analysis, as opposed to, say, being able to use applications like Photoshop, which almost every visual artist knows how to use).

As in the arts – so in business: eyes roll when the subject turns to IT (Information Technology). Some people are just not that into it; but sometimes it’s just that they are intimidated by it - convinced from the outset that they’ll never get it. It’s a protection mechanism. (Either way, it’s something BAs need to be aware of. One practical implication, for example, is that the documentation that is presented to non-technical audiences should not lean too heavily on analysis diagrams: their association with IT is enough to damn them for many readers.)

In any case, I don’t mean to rag on my artist friends. The ‘2 solitudes’ argument cuts both ways. Few of my friends in the IT world are interested in art either: they don’t go to art shows, don’t buy art (posters don’t count); don’t look at paintings or ‘art’ photographs. The reasons, I think, are pretty much the same as for the artists who don’t do IT: not interested, or convinced they’d never get it. For the second group - those who are simply intimidated by art but want to know more, it helps to have a guide.

At the moment (and for the next week), I have a show of paintings up in a gallery. I’ve been taking people on ‘guided tours’ of the show – each time focusing on a different piece.

This blog is a virtual version of that – focusing on one of the paintings in the current show, ‘Colossus’.

The title refers to another painting by the same – ‘The Colossus”, attributed to Francesco Goya, a Spanish painter who painted it in the early 1800’s. Goya lived in a time of great upheaval and war – and this is reflected in his work. In the original painting, the Colossus is a giant man who towers in the sky above the human turbulence below.

My painting is not an attempt to redo the Goya; it’s more of a riff on it. In my version, the Colossus of the Goya has been replaced by … well, me. But I’m standing on solid ground, not striding across the sky. And I’m wearing Sorel winter boots. (Because this is Canada.) This is one of the first paintings I started while working on the show, but I finished it last. It’s a summing up of all that I’d done in series. Its subject is war and people on the move, the migrations we hear about every day in the news and the endless migrations that have preceded them. The people in the painting come from: a photograph, a painting of a village by the French artist, Eugene Boudin, and one or two Black paintings by Goya – a mixing of pasts and the present and timeless wanderings.

This remixing of disparate sources is something that art - the process of making it and looking at it - excels at: the ability to see, as in this case, that there is a way to make a connection between a contemporary photograph, an early French Impressionist painting and some very sombre Spanish depictions of the human condition in times of war.

Whereas science and technology are largely about following disciplined, repeatable processes to arrive at a result, art encourages the mind to wander between ideas and see unexpected relationships. It's a skill the Business Analyst needs to develop when looking, for example, for a common thread behind a slew of customer complaints or when coming up with a novel approach to solve a problem.

There's a bleed, in other words, between the ways of thinking promoted by art and those promoted by science. Which is why I think it's a good idea to explore both, as opposed to staying within one silo ... not that there's anything wrong with that.

And a couple more art links:

Howard Podeswa

P.S. After much work, the new edition of UML for the IT BA is now being printed. Many thanks to all those in the ModernAnalyst community who contributed their thoughts via this blog. While I wasn’t able to thank you all individually in the book, there is a big shout-out to the group in the book’s acknowledgements and, in particular, to Adrian Marchis, for establishing and supporting this vibrant community.

How much analysis do you really need to do?

Howard Podeswa — Sun, 03 May 2009 04:21:00 GMT

As a BA, one of the central guiding principles for me has always been, "If it isn't going to make a difference to the outcome, don't do it." Yet I see a lot of confusion amongst BAs about how much analysis to do on a given project. Are structural models (class diagrams and ERDs) always worth doing or are they a waste of time? How much detail should you put into the user requirements? Obviously, blindly creating documentation without understanding its value - or if it even has any value - is not useful. The problem is when to do what. I thought this would be the perfect forum to toss out the question: How much analysis do you really need to do? I invite all responses – pro and con, cool and heated.

My real aim here is to generate discussion, not to be proscriptive. To get the discussion started, I'll start with some general guidance I’ve found useful.

The degree of documentation and analysis required for a project depends on a number of factors, including the lifecycle approach being used on the project, the size of the project, the type of solution being contemplated (in-house or vendor solution), and the risk involved.

There are two broad categories of lifecycles used on projects: definitive lifecycles - which are well-defined processes – and empirical processes, which are less defined. Projects managed using definitive lifecycles will require more documentation; those using en empirical lifecycle will require less. For example, while in a definitive lifecycle you might produce complete user requirements – expressed, for example, as use-case specifications, with an empirical lifecycle this would be of little value, since the requirements are constantly in a state of flux. On the other hand, even on an empirical project, there is still a need to list (if not completely describe) user tasks (use-cases) early on so that the effort required for and cost of the project can be estimated.

With respect to size – the larger the project, the greater the need for documentation. The team is bigger, the problem is more complex and more dollars are at stake – all factors favouring heavy documentation.

Solution type is another important factor. In-house solutions favour more documentation; vendor-supplied off-the-shelf solutions favour less documentation. Business rules and requirements that are standard across an industry are more likely to be supported in an off-the-shelf solution – and, therefore represent less risk than requirements that are peculiar to a business area. Naturally, more effort and detail will go into documenting the high-risk requirements.

I’ve tried to summarize some of this in a table that looks at UML tool usage for projects based on their size, solution type and lifecycle approach. In the table, a ‘small’ project is one that has a short timeline and budget and does not involve a change to a business process; an example is a change to an existing screen, or the addition of a new query screen to an existing system. An example of a large project , on the other hand, is the introduction of a new business product or service. The notes in the last column of the table relate to new UML artifacts; however, where there are existing UML artifacts related to the problem, they should be reviewed, and amended as required. The table can be applied to non-UML projects simply by replacing the UML terms in the last column as follows:

‘Business process models’ – instead of ‘business use cases’
‘User requirements/ user tasks’ – instead of ‘system use cases’
‘Statechart diagrams ‘– instead of ‘state-machine diagrams’
‘Data models/ERDs ‘– instead of ‘class diagrams’

Tailoring UML tools usage to the project:

Project Size: Small

Solution type	Lifecycle	UML tools
In-house development	Empirical	Business use cases: May be skipped, as no changes made to business process. System Use Cases: List and name new use cases and alternate flows. Provide only brief summaries of each flow, since interaction details will be worked out through prototyping.[1] Class diagrams: Model new classes and relationships to discover structural business rules; may be skipped if problem well-understood. State-machine diagrams: May be skipped. Activity diagrams: May be skipped.
In-house development	Definitive	Business use cases: May be skipped, as no changes to business process.. System Use Cases: Complete Class diagrams: May be skipped if a simple change, such as query screen. However, if new business concepts introduced, model them and their relationships in order to discover structural business rules. State-machine diagrams: May be skipped Activity diagrams: Use as addendum for system use cases whose flows connect in complex ways.
Off-The-Shelf	All lifecycles	Business use cases: May be skipped, as no changes to business process. System Use Cases: List and name use cases and alternate flows. Provide only brief summaries of each flow, since interaction details will differ based on the vendor. Class diagrams: Model new classes and relationships to discover structural business rules – focusing on business objects and rules that must be complied with but are not standard in the industry. (This step may be skipped when the problem is well understood and the rules are standardized.) State-machine diagrams: May be skipped. Activity diagrams: May be skipped.

¹ Agile projects may use ‘user stories’ as an alternative to use cases.

Project Size: Large

Solution type	Lifecycle	UML tools
In-house development	Empirical	Business use cases: Complete (or use a non-UML alternative) in order to capture end-to-end business process workflow. System Use Cases: List and name new use cases and alternate flows. Provide only brief summaries of each flow, since interaction details will be worked out through prototyping. Class diagrams: Complete. Classes, relationships and numerical rules (multiplicities) are required for across-the-board business rules. State-machine diagrams: Use to analyze lifecycles of key business objects. Activity diagrams: Use to describe workflow of business use cases (business processes) and as part of user requirements, where flow is complex – for example, to indicate navigation through and between screens.
In-house development	Definitive	Business use cases: Complete. System Use Cases: Complete Class diagrams: Complete Activity diagrams: Use to describe workflow of business use cases (business processes) and as addendum for system use cases whose flows connect in complex ways.
Off-The-Shelf	Empirical	Business use cases (or a non-UML alternative): For high-risk processes that are not standard in the industry. System Use Cases: List and name use cases and alternate flows. Provide only brief summaries of each flow, since interaction details will differ based on the vendor. Class diagrams: Model classes and relationships to discover structural business rules that must be adhered to by vendor solution; focus on rules that are non-standard in the industry. State-machine diagrams: Create in order to analyze lifecycles of key business objects. Activity diagrams: Use to describe workflow of business use cases (business processes) and as part of user requirements, where flow is complex – for example, to indicate navigation through and between screens.
Off-The-Shelf	Definitive	Business use cases: For high-risk processes that are not standard in the industry. System Use Cases: List and name use cases and alternate flows. Provide only brief summaries of each flow, since interaction details will be differ based on the vendor. Class diagrams: Model classes and relationships to discover structural business rules that must be adhered to by vendor solution; focus on rules that are non-standard in the industry. Activity diagrams: Use to describe workflow of business use cases (business processes) focusing on processes that are non-standard in the industry. Use activity diagrams as an addendum for system use cases whose flows connect in complex ways.

Finally, keep in mind that we’re talking here only about the artifacts that are created for each project. Some of these will be directed to business stakeholders and some will only be distributed to other team members and solution providers. But that’s a topic for another column (and one that I address on a tool-by-tool basis in my book, The Business Analyst’s Handbook’).

In the meantime, I’m looking forward to having others weigh in on today’s question “How much analysis do you really need to do?”

Howard Podeswa
For more on this topic, please see The Business Analyst's Handbook and the upcoming release of UML for the IT Business Analyst, 2nd Edition

Why I Do This

Howard Podeswa — Fri, 13 Mar 2009 22:12:00 GMT

I was at a talk yesterday by American artist Lawrence Weiner. He spent half the time saying there was nothing he had to say about his art; the next half saying it. I enjoyed it thoroughly. Something he had to say really stuck with me: that art is all about creating a logical structure for viewing the world. It helped me understand why I make my living doing two things that seem so disparate: visual art (painting) and Business Analysis. There are many things I love about BA but the part I have the most passion for is visual modeling. Perhaps it’s because of what Weiner pointed out: like art, it’s about creating a logical structure that communicates a way of seeing the world (or a part of it). The types of models I am most interested in are referred to as logical models: the name itself gives away the connection to Weiner’s art objects.

I have never been much interested in the physical world – the world of gadgets and mechanical things; it’s always been the logical structures that underlie the real world (RW) that most interest me. What I love about logical visual modeling is that it strips away those pesky physical details to focus on logical structures. It turns out that this is a great boon to the BA. If we focus on physical details there is very little common language between a business person and a software developer. But if we talk model-talk (for example, using a visual language like the UML), well then we can have a nice discussion: we get each other.

I’ve always been attracted to pursuits where you can get complex results but you only have to remember a few basic elements. Maybe it’s because I’ve always had a lousy memory. As a developer, I was a retro fan of Assembler. I’ve never lost my fascination for how its small set of basic instructions could be used to construct the most complex systems. As a BA, I feel the same about the UML diagrams – especially class diagrams. Give me a few basic concepts modeling elements (generalization, association, ...) and I can model the most complex business system. How cool is that?

Howard Podeswa
His most recent book, The Business Analyst's Handbook may be purchased on amazon.ca, and amazon.com.